The deployment of software within an organization has traditionally been an expensive and time-consuming process. For example, an organization that wants to install an application program on each of its computer systems may need to have a technician go to each computer system and manually control the installation of the application program. To help reduce the expense and time of deploying application programs, an administrator of an organization may use a system management service to control the deployment. A system management service helps automate the installation of the application programs on the computer systems of the organization. The system management service could distribute and install various application programs on the desired computer systems. After an application program is installed on desired computer systems of the organization, the users of those computer systems can start to use the application program. Although system management services have achieved their goal of reducing expense and time, such static deployment of application programs has some disadvantages. First, even though the software may be installed on a certain computer system, the user may never use that application program. As a result, the installed application program is unnecessarily consuming resources (e.g., disk space) of the computer system. Second, a user who wants to use the application program may not have it installed on their computer system because it was not designated as a desired computer system during deployment. In such a case, an administrator may need to manually control the installation of the application program on that user's computer system.
Many application programs are developed to be “managed” applications that execute within the .NET Framework provided by Microsoft Corporation. The .NET Framework provides a common language runtime (“CLR”) that provides high-level operating system type services to the managed applications and serves as an execution engine for managed applications. The CLR ensures that managed applications do not take any unauthorized action. As such, the CLR acts as a “sandbox” within which managed applications execute. The CLR provides application domains (“appdomains”) in which different application programs can execute to help ensure that an errant application will not unduly affect the execution of another application program.
Dynamic deployment of managed applications has been developed to help overcome the disadvantages of static deployment of application programs. With dynamic deployment, a managed application can be dynamically downloaded and installed within the .NET Framework of a computer system as needed. Microsoft's ClickOnce deployment technology provides such dynamic deployment of managed applications. Dynamic deployment allows a hosting program executing on a computer system to dynamically deploy a managed application to that computer system. As an initial step, a managed application that is to be dynamically deployed needs its application manifest (or an assembly manifest) published to a deployment server. (The application manifest may be identified in a deployment manifest that also identifies the version of the custom code identified by the application manifest.) The application manifest specifies the location of the components of the managed application (e.g., on a server other than the deployment server), identifies the provider of the managed application, and provides security requirements needed to execute the managed application. The hosting program is then provided with the identifier (e.g., URL) of the application manifest. To deploy the application program, the hosting program uses the manifest identifier to retrieve the manifest from the deployment server. The hosting program can then download the components specified in the manifest, install the managed application within the .NET Framework, and start the execution of the managed application in an appdomain that is separate from the appdomain of the hosting program. To help the hosting program with deploying managed applications, the ClickOnce deployment technology provides an in place hosting manager class (“IPHM”). The hosting program instantiates an in place hosting manager object and requests the object to install the managed application specified by the application manifest. The in place hosting manager object may help ensure that the managed application can be trusted (e.g., by comparing the provider to lists of trusted or untrusted providers). The in place hosting manager object may also ensure that the managed application executes with the security level specified in the application manifest. The in place hosting manager object may cache the downloaded managed application so that it can subsequently load the managed application without having to download it again from a server. As needed, the in place hosting manager object will automatically remove managed applications from the cache. The in place hosting manager object may also ensure that the most recent version of a managed application is loaded.
Many application programs, both managed and unmanaged, allow custom code (e.g., addins and document-level customizations) to be provided by third parties. Such application programs expose functionality that can be used by the custom code. The custom code may improve the usability of the application programs or provide additional functionality (e.g., domain-specific functionality). Custom code logically executes in the same process space or appdomain as the application program, rather than as an executable application. Because of the ease of developing custom code as managed code, many application programs support the execution of custom code in the NET Framework. The custom code may be stored as a dynamic link library, which can be loaded into the appdomain of the application program. There is, however, no mechanism for dynamically deploying custom code from network servers to computer systems.